home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_3.lha / rfc1247 < prev   
Text File  |  1995-07-26  |  36KB  |  873 lines

  1.  
  2.  
  3.  
  4.  
  5. Network Working Group                                             J. Moy
  6. Request for Comments: 1247                                 Proteon, Inc.
  7. Obsoletes: RFC 1131                                            July 1991
  8.  
  9.  
  10.                              OSPF Version 2
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16. This RFC specifies an IAB standards track protocol for the Internet
  17. community, and requests discussion and suggestions for improvements.
  18. Please refer to the current edition of the ``IAB Official Protocol
  19. Standards'' for the standardization state and status of this protocol.
  20. Distribution of this memo is unlimited.
  21.  
  22.  
  23. Abstract
  24.  
  25. This memo documents version 2 of the OSPF protocol.  OSPF is a link-
  26. state based routing protocol.  It is designed to be run internal to a
  27. single Autonomous System.  Each OSPF router maintains an identical
  28. database describing the Autonomous System's topology.  From this
  29. database, a routing table is calculated by constructing a shortest-path
  30. tree.
  31.  
  32. OSPF recalculates routes quickly in the face of topological changes,
  33. utilizing a minimum of routing protocol traffic.  OSPF provides support
  34. for equal-cost multipath.  Separate routes can be calculated for each IP
  35. type of service.  An area routing capability is provided, enabling an
  36. additional level of routing protection and a reduction in routing
  37. protocol traffic.  In addition, all OSPF routing protocol exchanges are
  38. authenticated.
  39.  
  40. Version 1 of the OSPF protocol was documented in RFC 1131.  The
  41. differences between the two versions are explained in Appendix F.
  42.  
  43. Please send comments to ospf@trantor.umd.edu.
  44.  
  45.  
  46. 1. Introduction
  47.  
  48. This document is a specification of the Open Shortest Path First (OSPF)
  49. internet routing protocol.  OSPF is classified as an Internal Gateway
  50. Protocol (IGP).  This means that it distributes routing information
  51. between routers belonging to a single Autonomous System.  The OSPF
  52. protocol is based on SPF or link-state technology.  This is a departure
  53.  
  54.  
  55.  
  56. [Moy]                                                           [Page 1]
  57.  
  58. RFC 1247                     OSPF Version 2                    July 1991
  59.  
  60.  
  61. from the Bellman-Ford base used by traditional internet routing
  62. protocols.
  63.  
  64. The OSPF protocol was developed by the OSPF working group of the
  65. Internet Engineering Task Force.  It has been designed expressly for the
  66. internet environment, including explicit support for IP subnetting,
  67. TOS-based routing and the tagging of externally-derived routing
  68. information.  OSPF also provides for the authentication of routing
  69. updates, and utilizes IP multicast when sending/receiving the updates.
  70. In addition, much work has been done to produce a protocol that responds
  71. quickly to topology changes, yet involves small amounts of routing
  72. protocol traffic.
  73.  
  74. The author would like to thank Rob Coltun, Milo Medin, Mike Petry and
  75. the rest of the OSPF working group for the ideas and support they have
  76. given to this project.
  77.  
  78.  
  79. 1.1 Protocol overview
  80.  
  81. OSPF routes IP packets based solely on the destination IP address and IP
  82. Type of Service found in the IP packet header.  IP packets are routed
  83. "as is" -- they are not encapsulated in any further protocol headers as
  84. they transit the Autonomous System.  OSPF is a dynamic routing protocol.
  85. It quickly detects topological changes in the AS (such as router
  86. interface failures) and calculates new loop-free routes after a period
  87. of convergence.  This period of convergence is short and involves a
  88. minimum of routing traffic.
  89.  
  90. In an SPF-based routing protocol, each router maintains a database
  91. describing the Autonomous System's topology.  Each participating router
  92. has an identical database.  Each individual piece of this database is a
  93. particular router's local state (e.g., the router's usable interfaces
  94. and reachable neighbors).  The router distributes its local state
  95. throughout the Autonomous System by flooding.
  96.  
  97. All routers run the exact same algorithm, in parallel.  From the
  98. topological database, each router constructs a tree of shortest paths
  99. with itself as root.  This shortest-path tree gives the route to each
  100. destination in the Autonomous System.  Externally derived routing
  101. information appears on the tree as leaves.
  102.  
  103. OSPF calculates separate routes for each Type of Service (TOS).  When
  104. several equal-cost routes to a destination exist, traffic is distributed
  105. equally among them.  The cost of a route is described by a single
  106. dimensionless metric.
  107.  
  108. OSPF allows sets of networks to be grouped together.  Such a grouping is
  109.  
  110.  
  111.  
  112. [Moy]                                                           [Page 2]
  113.  
  114. RFC 1247                     OSPF Version 2                    July 1991
  115.  
  116.  
  117. called an area.  The topology of an area is hidden from the rest of the
  118. Autonomous System.  This information hiding enables a significant
  119. reduction in routing traffic.  Also, routing within the area is
  120. determined only by the area's own topology, lending the area protection
  121. from bad routing data.  An area is a generalization of an IP subnetted
  122. network.
  123.  
  124. OSPF enables the flexible configuration of IP subnets.  Each route
  125. distributed by OSPF has a destination and mask.  Two different subnets
  126. of the same IP network number may have different sizes (i.e., different
  127. masks).  This is commonly referred to as variable length subnets.  A
  128. packet is routed to the best (i.e., longest or most specific) match.
  129. Host routes are considered to be subnets whose masks are "all ones"
  130. (0xffffffff).
  131.  
  132. All OSPF protocol exchanges are authenticated.  This means that only
  133. trusted routers can participate in the Autonomous System's routing.  A
  134. variety of authentication schemes can be used; a single authentication
  135. scheme is configured for each area.  This enables some areas to use much
  136. stricter authentication than others.
  137.  
  138. Externally derived routing data (e.g., routes learned from the Exterior
  139. Gateway Protocol (EGP)) is passed transparently throughout the
  140. Autonomous System.  This externally derived data is kept separate from
  141. the OSPF protocol's link state data.  Each external route can also be
  142. tagged by the advertising router, enabling the passing of additional
  143. information between routers on the boundaries of the Autonomous System.
  144.  
  145.  
  146. 1.2 Definitions of commonly used terms
  147.  
  148. Here is a collection of definitions for terms that have a specific
  149. meaning to the protocol and that are used throughout the text.  The
  150. reader unfamiliar with the Internet Protocol Suite is referred to [RS-
  151. 85-153] for an introduction to IP.
  152.  
  153.  
  154. Router
  155.     A level three Internet Protocol packet switch.  Formerly called a
  156.     gateway in much of the IP literature.
  157.  
  158. Autonomous System
  159.     A group of routers exchanging routing information via a common
  160.     routing protocol.  Abbreviated as AS.
  161.  
  162. Internal Gateway Protocol
  163.     The routing protocol spoken by the routers belonging to an
  164.     Autonomous system.  Abbreviated as IGP.  Each Autonomous System has
  165.  
  166.  
  167.  
  168. [Moy]                                                           [Page 3]
  169.  
  170. RFC 1247                     OSPF Version 2                    July 1991
  171.  
  172.  
  173.     a single IGP.  Different Autonomous Systems may be running different
  174.     IGPs.
  175.  
  176. Router ID
  177.     A 32-bit number assigned to each router running the OSPF protocol.
  178.     This number uniquely identifies the router within an Autonomous
  179.     System.
  180.  
  181. Network
  182.     In this paper, an IP network or subnet.  It is possible for one
  183.     physical network to be assigned multiple IP network/subnet numbers.
  184.     We consider these to be separate networks.  Point-to-point physical
  185.     networks are an exception - they are considered a single network no
  186.     matter how many (if any at all) IP network/subnet numbers are
  187.     assigned to them.
  188.  
  189. Network mask
  190.     A 32-bit number indicating the range of IP addresses residing on a
  191.     single IP network/subnet.  This specification displays network masks
  192.     as hexadecimal numbers.  For example, the network mask for a class C
  193.     IP network is displayed as 0xffffff00.  Such a mask is often
  194.     displayed elsewhere in the literature as 255.255.255.0.
  195.  
  196. Multi-access networks
  197.     Those physical networks that support the attachment of multiple
  198.     (more than two) routers.  Each pair of routers on such a network is
  199.     assumed to be able to communicate directly (e.g., multi-drop
  200.     networks are excluded).
  201.  
  202. Interface
  203.     The connection between a router and one of its attached networks.
  204.     An interface has state information associated with it, which is
  205.     obtained from the underlying lower level protocols and the routing
  206.     protocol itself.  An interface to a network has associated with it a
  207.     single IP address and mask (unless the network is an unnumbered
  208.     point-to-point network).  An interface is sometimes also referred to
  209.     as a link.
  210.  
  211. Neighboring routers
  212.     Two routers that have interfaces to a common network.  On multi-
  213.     access networks, neighbors are dynamically discovered by OSPF's
  214.     Hello Protocol.
  215.  
  216. Adjacency
  217.     A relationship formed between selected neighboring routers for the
  218.     purpose of exchanging routing information.  Not every pair of
  219.     neighboring routers become adjacent.
  220.  
  221.  
  222.  
  223.  
  224. [Moy]                                                           [Page 4]
  225.  
  226. RFC 1247                     OSPF Version 2                    July 1991
  227.  
  228.  
  229. Link state advertisement
  230.     Describes to the local state of a router or network.  This includes
  231.     the state of the router's interfaces and adjacencies.  Each link
  232.     state advertisement is flooded throughout the routing domain.  The
  233.     collected link state advertisements of all routers and networks
  234.     forms the protocol's topological database.
  235.  
  236. Hello protocol
  237.     The part of the OSPF protocol used to establish and maintain
  238.     neighbor relationships.  On multi-access networks the Hello protocol
  239.     can also dynamically discover neighboring routers.
  240.  
  241. Designated Router
  242.     Each multi-access network that has at least two attached routers has
  243.     a Designated Router.  The Designated Router generates a link state
  244.     advertisement for the multi-access network and has other special
  245.     responsibilities in the running of the protocol.  The Designated
  246.     Router is elected by the Hello Protocol.
  247.  
  248.     The Designated Router concept enables a reduction in the number of
  249.     adjacencies required on a multi-access network.  This in turn
  250.     reduces the amount of routing protocol traffic and the size of the
  251.     topological database.
  252.  
  253. Lower-level protocols
  254.     The underlying network access protocols that provide services to the
  255.     Internet Protocol and in turn the OSPF protocol.  Examples of these
  256.     are the X.25 packet and frame levels for PDNs, and the ethernet data
  257.     link layer for ethernets.
  258.  
  259.  
  260. 1.3 Brief history of SPF-based routing technology
  261.  
  262. OSPF is an SPF-based routing protocol.  Such protocols are also referred
  263. to in the literature as link-state or distributed-database protocols.
  264. This section gives a brief description of the developments in SPF-based
  265. technology that have influenced the OSPF protocol.
  266.  
  267. The first SPF-based routing protocol was developed for use in the
  268. ARPANET packet switching network.  This protocol is described in
  269. [McQuillan].  It has formed the starting point for all other SPF-based
  270. protocols.  The homogeneous Arpanet environment, i.e., single-vendor
  271. packet switches connected by synchronous serial lines, simplified the
  272. design and implementation of the original protocol.
  273.  
  274. Modifications to this protocol were proposed in [Perlman].  These
  275. modifications dealt with increasing the fault tolerance of the routing
  276. protocol through, among other things, adding a checksum to the link
  277.  
  278.  
  279.  
  280. [Moy]                                                           [Page 5]
  281.  
  282. RFC 1247                     OSPF Version 2                    July 1991
  283.  
  284.  
  285. state advertisements (thereby detecting database corruption).  The paper
  286. also included means for reducing the routing traffic overhead in an
  287. SPF-based protocol.  This was accomplished by introducing mechanisms
  288. which enabled the interval between link state advertisements to be
  289. increased by an order of magnitude.
  290.  
  291. An SPF-based algorithm has also been proposed for use as an ISO IS-IS
  292. routing protocol.  This protocol is described in [DEC].  The protocol
  293. includes methods for data and routing traffic reduction when operating
  294. over broadcast networks.  This is accomplished by election of a
  295. Designated Router for each broadcast network, which then originates a
  296. link state advertisement for the network.
  297.  
  298. The OSPF subcommittee of the IETF has extended this work in developing
  299. the OSPF protocol.  The Designated Router concept has been greatly
  300. enhanced to further reduce the amount of routing traffic required.
  301. Multicast capabilities are utilized for additional routing bandwidth
  302. reduction.  An area routing scheme has been developed enabling
  303. information hiding/protection/reduction.  Finally, the algorithm has
  304. been modified for efficient operation in the internet environment.
  305.  
  306.  
  307. 1.4 Organization of this document
  308.  
  309. The first three sections of this specification give a general overview
  310. of the protocol's capabilities and functions.  Sections 4-16 explain the
  311. protocol's mechanisms in detail.  Packet formats, protocol constants,
  312. configuration items and required management statistics are specified in
  313. the appendices.
  314.  
  315. Labels such as HelloInterval encountered in the text refer to protocol
  316. constants.  They may or may not be configurable.  The architectural
  317. constants are explained in Appendix B.  The configurable constants are
  318. explained in Appendix C.
  319.  
  320. The detailed specification of the protocol is presented in terms of data
  321. structures.  This is done in order to make the explanation more precise.
  322. Implementations of the protocol are required to support the
  323. functionality described, but need not use the precise data structures
  324. that appear in this paper.
  325.  
  326.  
  327. 2. The Topological Database
  328.  
  329. The database of the Autonomous System's topology describes a directed
  330. graph.  The vertices of the graph consist of routers and networks.  A
  331. graph edge connects two routers when they are attached via a physical
  332. point-to-point network.  An edge connecting a router to a network
  333.  
  334.  
  335.  
  336. [Moy]                                                           [Page 6]
  337.  
  338. RFC 1247                     OSPF Version 2                    July 1991
  339.  
  340.  
  341. indicates that the router has an interface on the network.
  342.  
  343. The vertices of the graph can be further typed according to function.
  344. Only some of these types carry transit data traffic; that is, traffic
  345. that is neither locally originated nor locally destined.  Vertices that
  346. can carry transit traffic are indicated on the graph by having both
  347. incoming and outgoing edges.
  348.  
  349.  
  350.  
  351.                    Vertex type   Vertex name    Transit?
  352.                    _____________________________________
  353.                    1             Router         yes
  354.                    2             Network        yes
  355.                    3             Stub network   no
  356.  
  357.  
  358.                         Table 1: OSPF vertex types.
  359.  
  360.  
  361. OSPF supports the following types of physical networks:
  362.  
  363.  
  364. Point-to-point networks
  365.     A network that joins a single pair of routers.  A 56Kb serial line
  366.     is an example of a point-to-point network.
  367.  
  368. Broadcast networks
  369.     Networks supporting many (more than two) attached routers, together
  370.     with the capability to address a single physical message to all of
  371.     the attached routers (broadcast).  Neighboring routers are
  372.     discovered dynamically on these nets using OSPF's Hello Protocol.
  373.     The Hello Protocol itself takes advantage of the broadcast
  374.     capability.  The protocol makes further use of multicast
  375.     capabilities, if they exist.  An ethernet is an example of a
  376.     broadcast network.
  377.  
  378. Non-broadcast networks
  379.     Networks supporting many (more than two) routers, but having no
  380.     broadcast capability.  Neighboring routers are also discovered on
  381.     these nets using OSPF's Hello Protocol.  However, due to the lack of
  382.     broadcast capability, some configuration information is necessary
  383.     for the correct operation of the Hello Protocol.  On these networks,
  384.     OSPF protocol packets that are normally multicast need to be sent to
  385.     each neighboring router, in turn.  An X.25 Public Data Network (PDN)
  386.     is an example of a non-broadcast network.
  387.  
  388.  
  389.  
  390.  
  391.  
  392. [Moy]                                                           [Page 7]
  393.  
  394. RFC 1247                     OSPF Version 2                    July 1991
  395.  
  396.  
  397. The neighborhood of each network node in the graph depends on whether
  398. the network has multi-access capabilities (either broadcast or non-
  399. broadcast) and, if so, the number of routers having an interface to the
  400. network.  The three cases are depicted in Figure 1.  Rectangles indicate
  401. routers.  Circles and oblongs indicate multi-access networks.  Router
  402. names are prefixed with the letters RT and network names with N.  Router
  403. interface names are prefixed by I.  Lines between routers indicate
  404. point-to-point networks.  The left side of the figure shows a network
  405. with its connected routers, with the resulting graph shown on the right.
  406.  
  407.  
  408. Two routers joined by a point-to-point network are represented in the
  409. directed graph as being directly connected by a pair of edges, one in
  410. each direction.  Interfaces to physical point-to-point networks need not
  411. be assigned IP addresses.  Such a point-to-point network is called
  412. unnumbered.  The graphical representation of point-to-point networks is
  413. designed so that unnumbered networks can be supported naturally.  When
  414. interface addresses exist, they are modelled as stub routes.  Note that
  415. each router would then have a stub connection to the other router's
  416. interface address (see Figure 1).
  417.  
  418. When multiple routers are attached to a multi-access network, the
  419. directed graph shows all routers bidirectionally connected to the
  420. network vertex (again, see Figure 1).  If only a single router is
  421. attached to a multi-access network, the network will appear in the
  422. directed graph as a stub connection.
  423.  
  424. Each network (stub or transit) in the graph has an IP address and
  425. associated network mask.  The mask indicates the number of nodes on the
  426. network.  Hosts attached directly to routers (referred to as host
  427. routes) appear on the graph as stub networks.  The network mask for a
  428. host route is always 0xffffffff, which indicates the presence of a
  429. single node.
  430.  
  431. Figure 2 shows a sample map of an Autonomous System.  The rectangle
  432. labelled H1 indicates a host, which has a SLIP connection to router
  433. RT12.  Router RT12 is therefore advertising a host route.  Lines between
  434.  
  435.  
  436.                  ______________________________________
  437.  
  438.                  (Figure not included in text version.)
  439.  
  440.                     Figure 1: Network map components
  441.                  ______________________________________
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448. [Moy]                                                           [Page 8]
  449.  
  450. RFC 1247                     OSPF Version 2                    July 1991
  451.  
  452.  
  453. routers indicate physical point-to-point networks.  The only point-to-
  454. point network that has been assigned interface addresses is the one
  455. joining routers RT6 and RT10.  Routers RT5 and RT7 have EGP connections
  456. to other Autonomous Systems.  A set of EGP-learned routes have been
  457. displayed for both of these routers.
  458.  
  459.  
  460. A cost is associated with the output side of each router interface.
  461. This cost is configurable by the system administrator.  The lower the
  462. cost, the more likely the interface is to be used to forward data
  463. traffic.  Costs are also associated with the externally derived routing
  464. data (e.g., the EGP-learned routes).
  465.  
  466. The directed graph resulting from the map in Figure 2 is depicted in
  467. Figure 3.  Arcs are labelled with the cost of the corresponding router
  468. output interface.  Arcs having no labelled cost have a cost of 0.  Note
  469. that arcs leading from networks to routers always have cost 0; they are
  470. significant nonetheless.  Note also that the externally derived routing
  471. data appears on the graph as stubs.
  472.  
  473.  
  474. The topological database (or what has been referred to above as the
  475. directed graph) is pieced together from link state advertisements
  476. generated by the routers.  The neighborhood of each transit vertex is
  477. represented in a single, separate link state advertisement.  Figure 4
  478. shows graphically the link state representation of the two kinds of
  479. transit vertices: routers and multi-access networks.  Router RT12 has an
  480.  
  481.  
  482.                  ______________________________________
  483.  
  484.                  (Figure not included in text version.)
  485.  
  486.                   Figure 2: A sample Autonomous System
  487.                  ______________________________________
  488.  
  489.  
  490.  
  491.                __________________________________________
  492.  
  493.                 (Figures not included in text version.)
  494.  
  495.                  Figure 3: The resulting directed graph
  496.                Figure 4: Individual link state components
  497.                __________________________________________
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504. [Moy]                                                           [Page 9]
  505.  
  506. RFC 1247                     OSPF Version 2                    July 1991
  507.  
  508.  
  509. interface to two broadcast networks and a SLIP line to a host.  Network
  510. N6 is a broadcast network with three attached routers.  The cost of all
  511. links from network N6 to its attached routers is 0.  Note that the link
  512. state advertisement for network N6 is actually generated by one of the
  513. attached routers: the router that has been elected Designated Router for
  514. the network.
  515.  
  516.  
  517. 2.1 The shortest-path tree
  518.  
  519. When no OSPF areas are configured, each router in the Autonomous System
  520. has an identical topological database, leading to an identical graphical
  521. representation.  A router generates its routing table from this graph by
  522. calculating a tree of shortest paths with the router itself as root.
  523. Obviously, the shortest-path tree depends on the router doing the
  524. calculation.  The shortest-path tree for router RT6 in our example is
  525. depicted in Figure 5.
  526.  
  527.  
  528. The tree gives the entire route to any destination network or host.
  529. However, only the next hop to the destination is used in the forwarding
  530. process.  Note also that the best route to any router has also been
  531. calculated.  For the processing of external data, we note the next hop
  532. and distance to any router advertising external routes.  The resulting
  533. routing table for router RT6 is pictured in Table 2.  Note that there is
  534. a separate route for each end of a numbered serial line (in this case,
  535. the serial line between routers RT6 and RT10).
  536.  
  537.  
  538. Routes to networks belonging to other AS'es (such as N12) appear as
  539. dashed lines on the shortest path tree in Figure 5.  Use of this
  540. externally derived routing information is considered in the next
  541. section.
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.                  ______________________________________
  549.  
  550.                  (Figure not included in text version.)
  551.  
  552.                  Figure 5: The SPF tree for router RT6
  553.                  ______________________________________
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560. [Moy]                                                          [Page 10]
  561.  
  562. RFC 1247                     OSPF Version 2                    July 1991
  563.  
  564.  
  565.  
  566.  
  567.                    Destination   Next  Hop   Distance
  568.                    __________________________________
  569.                    N1            RT3         10
  570.                    N2            RT3         10
  571.                    N3            RT3         7
  572.                    N4            RT3         8
  573.                    Ib            *           7
  574.                    Ia            RT10        12
  575.                    N6            RT10        8
  576.                    N7            RT10        12
  577.                    N8            RT10        10
  578.                    N9            RT10        11
  579.                    N10           RT10        13
  580.                    N11           RT10        14
  581.                    H1            RT10        21
  582.                    __________________________________
  583.                    RT5           RT5         6
  584.                    RT7           RT10        8
  585.  
  586.  
  587.     Table 2: The portion of router RT6's routing table listing local
  588.                              destinations.
  589.  
  590. 2.2 Use of external routing information
  591.  
  592. After the tree is created the external routing information is examined.
  593. This external routing information may originate from another routing
  594. protocol such as EGP, or be statically configured (static routes).
  595. Default routes can also be included as part of the Autonomous System's
  596. external routing information.
  597.  
  598. External routing information is flooded unaltered throughout the AS.  In
  599. our example, all the routers in the Autonomous System know that router
  600. RT7 has two external routes, with metrics 2 and 9.
  601.  
  602. OSPF supports two types of external metrics.  Type 1 external metrics
  603. are equivalent to the link state metric.  Type 2 external metrics are
  604. greater than the cost of any path internal to the AS.  Use of Type 2
  605. external metrics assumes that routing between AS'es is the major cost of
  606. routing a packet, and eliminates the need for conversion of external
  607. costs to internal link state metrics.
  608.  
  609. Here is an example of Type 1 external metric processing.  Suppose that
  610. the routers RT7 and RT5 in Figure 2 are advertising Type 1 external
  611. metrics.  For each external route, the distance from Router RT6 is
  612. calculated as the sum of the external route's cost and the distance from
  613.  
  614.  
  615.  
  616. [Moy]                                                          [Page 11]
  617.  
  618. RFC 1247                     OSPF Version 2                    July 1991
  619.  
  620.  
  621. Router RT6 to the advertising router.  For every external destination,
  622. the router advertising the shortest route is discovered, and the next
  623. hop to the advertising router becomes the next hop to the destination.
  624.  
  625. Both Router RT5 and RT7 are advertising an external route to destination
  626. network N12.  Router RT7 is preferred since it is advertising N12 at a
  627. distance of 10 (8+2) to Router RT6, which is better than router RT5's 14
  628. (6+8).  Table 3 shows the entries that are added to the routing table
  629. when external routes are examined:
  630.  
  631.  
  632.  
  633.                      Destination   Next  Hop   Distance
  634.                      __________________________________
  635.                      N12           RT10        10
  636.                      N13           RT5         14
  637.                      N14           RT5         14
  638.                      N15           RT10        17
  639.  
  640.  
  641.     Table 3: The portion of router RT6's routing table listing external
  642.                                destinations.
  643.  
  644.  
  645. Processing of Type 2 external metrics is simpler.  The AS boundary
  646. router advertising the smallest external metric is chosen, regardless of
  647. the internal distance to the AS boundary router.  Suppose in our example
  648. both router RT5 and router RT7 were advertising Type 2 external routes.
  649. Then all traffic destined for network N12 would be forwarded to router
  650. RT7, since 2 < 8.  When several equal-cost Type 2 routes exist, the
  651. internal distance to the advertising routers is used to break the tie.
  652.  
  653. Both Type 1 and Type 2 external metrics can be present in the AS at the
  654. same time.  In that event, Type 1 external metrics always take
  655. precedence.
  656.  
  657. This section has assumed that packets destined for external destinations
  658. are always routed through the advertising AS boundary router.  This is
  659. not always desirable.  For example, suppose in Figure 2 there is an
  660. additional router attached to network N6, called Router RTX.  Suppose
  661. further that RTX does not participate in OSPF routing, but does exchange
  662. EGP information with the AS boundary router RT7.  Then, router RT7 would
  663. end up advertising OSPF external routes for all destinations that should
  664. be routed to RTX.  An extra hop will sometimes be introduced if packets
  665. for these destinations need always be routed first to router RT7 (the
  666. advertising router).
  667.  
  668. To deal with this situation, the OSPF protocol allows an AS boundary
  669.  
  670.  
  671.  
  672. [Moy]                                                          [Page 12]
  673.  
  674. RFC 1247                     OSPF Version 2                    July 1991
  675.  
  676.  
  677. router to specify a "forwarding address" in its external advertisements.
  678. In the above example, Router RT7 would specify RTX's IP address as the
  679. "forwarding address" for all those destinations whose packets should be
  680. routed directly to RTX.
  681.  
  682. The "forwarding address" has one other application.  It enables routers
  683. in the Autonomous System's interior to function as "route servers".  For
  684. example, in Figure 2 the router RT6 could become a route server, gaining
  685. external routing information through a combination of static
  686. configuration and external routing protocols.  RT6 would then start
  687. advertising itself as an AS boundary router, and would originate a
  688. collection of OSPF external advertisements.  In each external
  689. advertisement, router RT6 would specify the correct Autonomous System
  690. exit point to use for the destination through appropriate setting of the
  691. advertisement's "forwarding address" field.
  692.  
  693.  
  694. 2.3 Equal-cost multipath
  695.  
  696. The above discussion has been simplified by considering only a single
  697. route to any destination.  In reality, if multiple equal-cost routes to
  698. a destination exist, they are all discovered and used.  This requires no
  699. conceptual changes to the algorithm, and its discussion is postponed
  700. until we consider the tree-building process in more detail.
  701.  
  702. With equal cost multipath, a router potentially has several available
  703. next hops towards any given destination.
  704.  
  705.  
  706. 2.4 TOS-based routing
  707.  
  708. OSPF can calculate a separate set of routes for each IP Type of Service.
  709. The IP TOS values are represented in OSPF exactly as they appear in the
  710. IP packet header.  This means that, for any destination, there can
  711. potentially be multiple routing table entries, one for each IP TOS.
  712.  
  713. Up to this point, all examples shown have assumed that routes do not
  714. vary on TOS.  In order to differentiate routes based on TOS, separate
  715. interface costs can be configured for each TOS.  For example, in Figure
  716. 2 there could be multiple costs (one for each TOS) listed for each
  717. interface.  A cost for TOS 0 must always be specified.
  718.  
  719. When interface costs vary based on TOS, a separate shortest path tree is
  720. calculated for each TOS (see Section 2.1).  In addition, external costs
  721. can vary based on TOS.  For example, in Figure 2 router RT7 could
  722. advertise a separate type 1 external metric for each TOS.  Then, when
  723. calculating the TOS X distance to network N15 the cost of the shortest
  724. TOS X path to RT7 would be added to the TOS X cost advertised by RT7
  725.  
  726.  
  727.  
  728. [Moy]                                                          [Page 13]
  729.  
  730. RFC 1247                     OSPF Version 2                    July 1991
  731.  
  732.  
  733. (see Section 2.2).
  734.  
  735. All OSPF implementations must be capable of calculating routes based on
  736. TOS.  However, OSPF routers can be configured to route all packets on
  737. the TOS 0 path (see Appendix C), eliminating the need to calculate non-
  738. zero TOS paths.  This can be used to conserve routing table space and
  739. processing resources in the router.  These TOS-0-only routers can be
  740. mixed with routers that do route based on TOS.  TOS-0-only routers will
  741. be avoided as much as possible when forwarding traffic requesting a
  742. non-zero TOS.
  743.  
  744. It may be the case that no path exists for some non-zero TOS, even if
  745. the router is calculating non-zero TOS paths.  In that case, packets
  746. requesting that non-zero TOS are routed along the TOS 0 path (see
  747. Section 11.1).
  748.  
  749.  
  750. 3. Splitting the AS into Areas
  751.  
  752. OSPF allows collections of contiguous networks and hosts to be grouped
  753. together.  Such a group, together with the routers having interfaces to
  754. any one of the included networks, is called an area.  Each area runs a
  755. separate copy of the basic SPF routing algorithm.  This means that each
  756. area has its own topological database and corresponding graph, as
  757. explained in the previous section.
  758.  
  759. The topology of an area is invisible from the inga smn toiate setlculating            directliste      ng he and
  760. procenioPPtiple equad   Juling thase spCioPPutinad iple equad  TOS 0 pathb1hs.  Ine  tiohis meaoforw    ing N1 11.Rd iple etrafhan[8uld
  761. end upi opol  inoduco
  762. con    trafhters wrafhadve than routethe esources in the rrea ipes of exten    trafhters wrafhadve than routethe esources in the rrea ipes of exten    tred with romSPFbd up adverkquala runs   th t
  763. assace  be i 6
  764. RT6T.  This means trnaetherr6tl   eAality, if oute to an to t  Thisidedrg
  765. be
  766. mixed would originate outeis
  767. calculated as the sum of tTomSPFginate outefhterious   gter is calculat
  768. te out7
  769.  
  770.  
  771.  
  772. rnaoul'non-zero TOS, evst for hat should
  773. be-shoulry external"route se ca 10the sarouter a
  774.  
  775. ach     ternal routlo
  776. responlimr-ODsv
  777. lat
  778. dverkqualaffic rnea h of uala runst ea11]
  779.  
  780. Rter RTOS (see ofSoutegf tTomSPFgiswRb7s tspecify RTquestim of tTomSPFginatehas bee
  781.  
  782. [Mea h s w-specified.
  783.  
  784. When interface costs vary based on TOS, a separate shortest path trest path taS.
  785.  
  786. Vers taS.
  787.  
  788. VerEachdedanycrated for ehe v ofetance from Routercenon-
  789. zero )kedanycrat Jul ters wrafhadve than roTOS, evst for hat shoeddr2metrrhe esouhe esources in thwiost of
  790. s TOS pathsalcuu
  791. dverks bFgiswRb7esources in opolllll      OS pat t  Th on TOSc avaprotocolsvert,
  792.  
  793.  
  794. [Mathe exter oute se5a disttnation.
  795.  
  796. B onlh
  797. be srious   gt pa
  798.  
  799.  
  800. [Mall ernaetherr6tl   eAality, i0te all packets on
  801. the        SPFg2ed
  802. urred since it ous   gteu
  803. dshortes
  804. calculat
  805. irable.d o, i0te all ps wrafot canioPear in,rou
  806. procenioPn ben adutes exismurces in the router.  Trrespondin
  807. is cac bsternal call out
  808. iTOS, 
  809. ipecifiscoswarded ny destin towaPn begiv
  810. questim6b ased bste in thydProcessingktionN1hs.  Ine achernaiat, fp,ltal advN1 1tIn orderoTOS,on 2              n arehrough the advertif
  811. OS.  HgktionN1hl psth romtIopy of tchernspecicipure opy od
  812. area.hbro TOS paf        F rout          RT10fiedfgiv
  813. questP TOSost machernspDa
  814. dmdf terfang ield.
  815.  
  816.  
  817. 2.3 Ed, eliminrehhat p      tined an     destin do limicuu
  818. dvo                     N15           RT10        17
  819.  
  820.  
  821.     Table 3: The portion ofat p42ed
  822. urred su     l   eAaliioP     eparatts not par     l   eAaliioP     eparatts not par     l   eAaliioP     eparatts not par   ga s   .  Taliis are     hen essingktioiepalcipecifisings   gt paAyd
  823. urr13]
  824.  
  825. n5nneroTSic for e gt paAherrate
  826. soTSic foifisy bas8gt paAh       
  827. n5ne  tiohis meaoforw    ic
  828. conf:palci in is car.  destie.d o,h
  829.  origi ttnatioOe rrea ideedardingee
  830.  
  831. [Meouadamd whrresps bFdardeddditionr1hl pstOcnmall
  832.  
  833. OSPdSPFb1va
  834. non0 pai0touped
  835. togen (see Sernal tia    cpy pe rfexterall
  836.  
  837. i    RT10    1va
  838. rpswRb7s tsp inllopiopiop and      eal witrred sinceric for each TOS.  Then,serve routing t
  839. cessing ofssumed that packfN1 1eal witrre8ga sRT10    1liio
  840.  erna in is cologr)hat noch area rutionasI p42e,dvN1
  841. "forwe and
  842. pro3dr1hcenon-
  843. smustspacecase thbeeus       
  844.    
  845. oul'sgt fat  rouhe es fsach aeeuters ic
  846.  
  847. ipS: The portion     nccforw
  848. rre8ga cce osts)candne  tio   l   eAaleeu17
  849.  
  850. gice osal a p42e pong interfaces :as8lateu17ga cSPdSipecual-clistedrectliste "e needouped
  851. tdP     epsrby RernalktionN1hl :a hop will 11srHn be ue an    0  Router 3: T outcal,arattces :as8la routee etrafhDe        .  ItIopzesoubordiiiirach    : opy iopiop a
  852. based n
  853. Qr eachcOS.
  854.  
  855. Isp inla separaess in
  856. ;9su coalculrnaling ing ing ing ing ing ing i2it can[tionN1hr. (dn
  857. con    tralgorhr.Wited n
  858. Qr e6tl  
  859. n5nbe i 
  860.  trerutilet enablesdn     nccforw
  861. rre8ga.sition, external g       .  ItIopzesouborddfgiOs not pluRnateTwitr)zesnet es rohe sternr2l   e outefhter7outed along the TOS 0 path (see
  862. Sectionviiiimixed wouldteTwitr)zesnetpro3SeclP address as akedernspecitas ien adu7he rreasoL,itr)eeuterss.
  863. `oer outd t
  864. TOSN1hior 
  865. B onlh
  866. bItinr 
  867. B o taS.oEeeutnocru
  868. prolsgf the shorte(Ip2aofh  ncberkqualpDa
  869. saddr, external  l   eA
  870.  
  871.  
  872. [MatshOSN1Tf Seni :a hop will 11srHn br enformatiote se ca 10ten aspl  l naicpes of "forwt
  873. TOSN nh this hernMatshOSN1Tf Se